Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Identity, Security and Trust

Every request in a health information exchange carries an implicit claim: I am this party, acting for this person, for this purpose, and I am permitted to do this. The security architecture is the machinery that makes each part of that claim verifiable.

It cannot be added later. Retrofitting identity onto an exchange that already runs on shared API keys means re-onboarding every participant.

Five kinds of identity​

They are frequently conflated, and each needs a different mechanism.

IdentityWho or whatEstablished byUsed for
Patient / clientThe person receiving careClient registry, national IDLinking records; patient-facing access
Health workerThe person providing careHealth worker registry + identity providerAttribution, authorisation
OrganisationThe legal entityOrganisation registry, certificatesTrust between institutions
System / machineAn application or serviceClient credentials, mutual TLS, signed JWTSystem-to-system exchange
ApplicationA specific piece of software acting for a userOAuth client registrationSMART on FHIR app access

A common architectural error is using one mechanism for all five — typically a shared API key that identifies neither the user, the organisation nor the purpose, and therefore renders the audit log useless at exactly the moment it is needed.

Authentication, authorisation, and the third question​

  • Authentication — who are you? Handled by an identity provider using OpenID Connect, SAML, certificates or credentials.
  • Authorisation — what may you do? Handled by policy, evaluated per request.
  • Consent — has the patient agreed to this? A separate question, with a separate answer, from a separate service. See consent and trust.

All three must be satisfied. A clinician may be authenticated, may hold a role permitting record access, and may still be prohibited from viewing a particular patient's record because there is no care relationship or the patient has restricted it.

Access control models​

ModelDecides onFitsLimitation
RBAC — role-basedThe user's roleSimple, stable organisationsRole explosion; cannot express "only my patients"
ABAC — attribute-basedAttributes of user, resource, action, contextHealth exchange, where context is everythingHarder to reason about and test
PBAC — policy-basedCentrally authored policy, evaluated at a decision pointMulti-organisation ecosystemsRequires a policy engine and its governance
ReBAC — relationship-basedThe relationship between user and subjectCare relationships, delegation, guardianshipRelationship data must exist and be current

Health almost always needs more than RBAC. "A nurse may read patient records" is not a usable rule; the rule is closer to "a nurse may read the records of patients with an active encounter at a facility where they hold a current posting, unless the patient has restricted access, except in a documented break-glass event."

That sentence contains user attributes, resource attributes, relationship, consent and an exception path — which is why the decision belongs in an explicit policy engine rather than scattered through application code.

The practical structure:

   Request
      │
      ▼
  ┌─────────────────┐        ┌────────────────────┐
  │ Policy          │───────▶│ Policy decision    │
  │ enforcement pt. │        │ point (PDP)        │
  │ (gateway/API)   │◀───────│  evaluates policy  │
  └─────────────────┘ permit └─────────┬──────────┘
      │              / deny            │ queries
      ▼                                ▼
   Resource                 identity provider · HWR ·
                            consent service · care
                            relationship service
      │
      ▼
   Audit event (always, permit or deny)

Denials must be audited as carefully as permissions. A pattern of denied requests is a signal.

Zero trust​

The assumption that being inside the network implies nothing. Every request is authenticated and authorised on its own merits.

This is the correct default for health information exchange, because the "internal network" spans organisations with different security postures, and a compromised clinic workstation is a normal event rather than a hypothetical.

In practice: strong workload identity, mutual TLS between services, per-request authorisation, no implicitly trusted network segments, and comprehensive logging. See security architecture and NIST SP 800-207.

In this section​

Tooling​

ToolRoleTier
KeycloakOpen-source identity and access management; OIDC, SAML, federation, token exchange. The default choice in many national deployments.2
Ory Hydra / KratosOAuth 2.0 server and identity management, API-first2
Open Policy Agent (OPA)General-purpose policy engine for externalising authorisation decisions2
HashiCorp Vault / OpenBaoSecrets and key management2
Cert-manager, step-caCertificate issuance and rotation2

None of these is health-specific. The health-specific part is the policy they enforce and the registries they consult.

References​

Last updated on